PROCESS FOR MONITORING THE QUALITY OF SERVICE IN A TELECOMMUNICATION 

NETWORK AND APPARATUS FOR THE SAME 



TECHNICAL FIELD OF THE INVENTION 

5 

The invention relates to telecommunications and, more particularly, to processes for monitoring 
quality of service over a telecommunication network and related apparatus and computer programs. 

BACKGROUND ART 

10 

New services are constantly being made available with the development of telecommunication 
networks and also that of the Internet. A new impetus for the emergence of new services has 
resulted from the convergence of packet-based networks with circuit-based networks, such as the 
traditional Public Switched Telephone Network (PSTN). 

15 

It can be observed that the traditional distinction between circuit-based networks - being at the core 
of traditional telecommunications - and packet-based networks which are at the heart of the 
Internet network, is disappearing. In the latest developments, the concept of session is being 
integrated into packet-based networks. Many applications and new services which are available to 

20 customers - and also those which will be offered in the near future - are based on the creation and 
the management of a session. Such a session allows an exchange of data between different 
participants who are reachable through their address and who can communicate through a wide 
range of different terminals, such as personal computers, Personal Document Assistant (PDA), 
portable computers, cellular telephones, fixed telephones, Universal Mobile Telecommunications 

25 System (UTMS) terminals, for instance. 

Substantial research and investigations have been carried out in order to define the concept of 
session in the traditional Internet network. Some of this work was carried out within the frame of 
the Internet Engineering Task Force (IETF) and have lead to the Session Initiation Protocol (SIP) 
30 which ties together the PSTN and the Internet . 

SIP is the core protocol enabling the setting up of conferencing, telephony, multimedia and other 
types of communication sessions on the Internet. It is expected to be at the heart of future high- 
quality voice sessions over packet networks, including wireless networks. With the development of 
35 the SIP protocol, there is provided the possibility of real time multimedia sessions, including voice, 
video and data. 
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More information concerning the SIP protocol can be found in RFC 3261 "SIP: Session Initiation 
Protocol". Extensions to SIP are being provided within the IETF in 
http : //www . ietf . org/ids . by . wg/sip . html 

5 

As a wider variety of telecommunications services are offered to customers of the era of 
information, including services based on the Web, multimedia services involving video and audio 
streaming, more and more attention is being directed to the general problem of the Quality of 
Service (QoS) . 

10 

Traditional Internet service providers and, more generally, the companies handling the 
telecommunication networks have already at least partially addressed the problem of measuring the 
actual quality of service offered to their customers and, therefore, some techniques are already 
known. 

15 

A first technique, illustrated in figure 1, is based on the use of a passive probe 3 which is piece of 
specialized equipment that is installed between two particular communicating nodes 1 and 2 
within a network 10. Such a passive probe is designed to monitor the traffic between the two 
nodes. By observing a certain number of parameters, and particularly the loss of packets, passive 
20 probe 3 can track the quality of the communication and can report a QoS measure to the service 
provider. 

A second technique is based on the use of an active probe, such as active probe 4 of figure 2 which 
- contrary to the passive probes - is designed to generate additional traffic and behave like an end- 
25 user generating traffic. For this reason, such active probes are also called end-user simulators 
which can, again, be used for tracking the quality of service of the communication as the packets 
are being conveyed throughout the network. 

I A third technique which is also known to the service operators involves processing the information 

30 provided by standard management interfaces (log files for Standard Network Management 
Protocols, for instance) in the network and which are constantly updated. 

While the known techniques do provide means to measure the quality of service within a 
communication network, they are generally reserved for use by service or network operators. 
35 They cannot normally be used at the level of the user who, certainly, may have a strong interest in 
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determining the precise measurement of the quality of service which they are experiencing, and for 
which they will be charged. 

SUMMARY OF THE INVENTION 

5 

In at least preferred embodiments, the present invention provides a process for monitoring the 
quality of service of the communication over an Internet or intranet network which is executed in a 
end-user terminal and which comprises the steps of establishing a session between a first end-user 
terminal and a system offering a service or a second end-user terminal via a signaling plane; and 
10 monitoring the quality of service of the communication during said session; transmitting to all 
communicating parties information representative of said quality of service via said signaling plane. 

By using the signal plane for the transmission of QoS statistics it can be seen that the transmission 
of such statistics becomes substantially independent of the type of media which is exchanged. This 

15 simplifies the monitoring process. Further, there is provided the possibility of real time 
measurement of the QoS of the session. In particular, in embodiments where the process is fully- 
compliant with the SIP protocol, the service provider and end-users will be given the possibility to 
share the same QoS information in a very flexible way. Since the QoS information is transmitted 
through the signaling plane - and not through the media or data path as in the traditional RTP and 

20 RTCP protocol, for instance, a very flexible monitoring process is achieved, and this irrespectively 
of the particular media transport involved. 

In a preferred embodiment, the information representative of said quality of service comprises 
signaling parameters and media transmission quality parameters. The signaling parameters include 
25 a parameter representative of the time taken between one invite or, more generally the time for the 
"caller" to contact the " callee", is transmitted to said first proxy and said proxy forwards it to 
said second proxy. Further, the signal parameters includes a parameter which is representative of 
the time between one invite and the resulting ringing signal for this invite. 

30 In addition, the QoS statistics can include parameters representative of the quality of transmission 
of voice signals. In one such embodiment, the voice is transmitted through RCP and RTCP 
protocols and said quality of service comprises parameters extracted from said RTCP protocol, and 
the quality of service comprises parameters representative of the jitter of the voice transmission, 
and/or the loss of packets in the transmission of voice. 

35 
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The invention also enables the provision of a new end-user terminal - and computer programs for 
use therein - such as a personal computer, a Personal Document Assistant (PDA), a portable 
computer, a cellular telephone, a fixed telephone or a Universal Mobile Telecommunications 
System (UTMS) terminal, which can exchange QoS statistics with other parties including other 
5 end-user terminals. 

In another aspect, the invention provides a process for monitoring the quality of service of a 
communication through a communication network, said process being executed in a proxy server. 
The process can comprise the steps of: extracting QoS information representative of measured 

10 quality of service measured at one or more session endpoints in one or more messages used in set- 
up or teardown of a session; processing said extracted QoS data, in a Systems management 
application, for instance, to produce displayable QoS parameters and displaying said parameters to 
a user via a user interface. Also provided is a proxy server comprising means to monitor QoS 
using the above described process and a computer program product, such as a systems management 

15 application, comprising program code elements for doing the same. 

DESCRIPTION OF THE DRAWINGS 

An embodiment of the invention will now be described, by way of example only, with reference to 
20 the accompanying drawings, wherein: 

Figure 1 illustrates a first prior art technique based on a passive probe. 

Figure 2 illustrates a second prior art technique which is based on the use of an active probe 
25 generating traffic to determine the quality of service within a network. 

Figure 3 is a schematic diagram illustrating a network within which a process is executed in order 
to monitor the quality of service experienced by the user. 

30 Figure 4 is a flow chart illustrating a process for monitoring the QoS. 

Figure 5 illustrates the different messages which are exchanged for establishing a SIP session. 

DESCRIPTION OF THE PREFERRED EMBODIMENT OF THE INVENTION 

35 
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With respect to figure 3 there will now be described a preferred embodiment of a process for 
measuring and monitoring the quality of service of a communication in a telecommunication 
network 20. Communication network 20 can be, for instance, a next generation network (NGN) 
which provides, in addition to the traditional internet services, e.g. web browsing or email, for 
5 instance, additional real time multimedia sessions, including voice, video and data. 

Services provided to an end-user terminal 21 may include services offered by a dedicated server 23 
as well as multimedia sessions with a second end-user terminal 22. A Service Level Agreement 
Management application in terminal 25 may be set up by the network or service operator for the 
10 purpose of tracking QoS information which will be exchanged by the end-user terminals 21 and 22 
as described below. 

End user-terminal 21 or 22 may be any suitable terminal providing access to an Internet or an 
Intranet network, such as but not limited to personal computers, Personal Document Assistants 
15 (PDA), portable computers, cellular telephones, fixed telephones, Universal Mobile 
Telecommunications System (UMTS) terminals, for instance. In figure 3, user-terminal 21 and 22 
are represented as two HP JORNADA type PDAs which are marketed by Hewlett-Packard 
Company. 

20 It will be understood that the described techniques may be used with any kind of connection to a 
network, such as, but not limited to, connection via a wired LAN, infrared connection, or an 
802.11 or other wireless connection, for instance. 

End-user terminals 21 and 22 include means for establishing sessions through the NGN network 20 
25 and this is accomplished by using an appropriate session initiating protocol. In the preferred 
embodiment, the known SIP protocol is used for establishing a session between end-user terminal 
21 and service 23 (or between end-user terminal 21 and end-user 22) although, clearly, the 
techniques described may also be implemented in any kind of equivalent or comparable session 
initiating protocols. The use of the techniques with the emerging SIP protocol is clearly an 
30 advantage since SIP is becoming a well known protocol for signaling in the next generation 
wireless networks. 

Such a session may be used for permitting all kinds of services, including, without restriction, 
voice, video, multimedia and instant messaging. Considering the SIP protocol, the session is 
35 established in accordance with a signaling procedure which employs a signaling plane. In 
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accordance with the known SIP technique, this signaling plane serve to establish and terminate 
sessions over the network. 

As known in the SIP procedure, the establishment of a session is achieved by means of a set of 
5 messages which are exchanged through the network in accordance with the SIP protocol and, more 
particularly, by an INVITE message which contains the SIP address of end-user terminal 22, for 
instance. For the sake of clarity, the contents of the SIP protocol will not be discussed in detail . 
However, additional references can be found in RFC3261 referred to above. 

10 In addition to the possibility of initiating a session, user terminal 21 includes means for monitoring 
the quality of service of the communication during the session. This is achieved by extracting 
relevant information from the appropriate protocol layer supporting the transport of the media, e.g. 
voice, video, multimedia etc... Rq>resentative parameters for such QoS information can be gathered 
and such QoS information is exchanged through the signaling plane of the SIP protocol in order to 

15 enable both end-user terminals 21 and 22, and also Service Level Management application 24 of 
the service or network operator, to have access to the same information when the session 
completes. To achieve this, signaling protocols are used in order to transport QoS information as 
measured at the session endpoints. 

20 With respect to figure 4, there will now be described a process for monitoring the QoS of the 
communication during a session between end-user terminals 21 and 22 illustrated in figure 3. 

The process starts with a step 41 where a call is initiated in accordance with the SIP procedure. 
Establishing a call for initiating a session is well understood and this will not be described in detail. 

25 This can be achieved, in accordance with the known SIP protocol by means of an INVITE message 
51 - in figure 5 - which is forwarded to proxy 1 associated with end-user 21. In the preferred 
embodiment, QoS information corresponding to the measured time elapsed between the initial 
INVITE request and its corresponding response is embedded within an appropriate header of the 
ACK message. In this way, terminal 21 and service 23 (or terminal 22) both have access to the 

30 same QoS information during the session. 

Once the session is established, the process proceeds with step 42 where the quality of the session 
is analysed and a number of parameters which are representative of the Quality of Service (QoS) of 
the communication are collected or computed. Such information may for instance include 
35 information relating to the quality of the call establishment (signaling level), the quality of the 
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media transmission (media streaming, jitter, loss of packets) and also the quality of the service 
provided by server 23. 



All these parameters constitute a set of QoS statistics relating to the current session, i.e. very 
5 useful information which can be used for checking compliance of the Service Level Agreement 
committed by the service or network operator. 

The appropriate parameters which are collected and which can be generated and computed from the 
extracted parameters closely depend upon the media which is transported during the session and the 
10 particular type of service. In one embodiment, the session is assumed to allow transmission of 
voice signals and the QoS statistics relate to parameters concerning the transmission of voice 
signals. Clearly, appropriate adaptions can be made to implement the techniques described for any 
kind of other services. 

15 In one embodiment, the Real Time Transfer Protocol (RTP) and RTP Control Protocol (RTCP) 
protocols are used for the purpose of transmitting voice signals over the Internet network. The 
process executed within end-user terminal 1 extracts from the parameters of those protocols QoS 
information relating to the quality of transmission, such as the average/variance of the jitter and the 
percentage of lost packets during the session, and such information is collected and forwarded to 

20 all the communicating parties via the signaling plane. 

When the session or call terminates, in a step 44, the process executed in end-user terminal 21 
transmits the QoS statistics to the service 23 or end-user terminal 22 (in accordance with the case 
considered) within a call termination message. In the same way, the other participating end-user 

25 terminal 22 forwards its own QoS statistics to terminal 21, so that both have access to the same 
QoS statistics and such information is common to the users and also to the service or network 
operator which can collects this information in the proxies. At the end of the call session, the QoS 
information can be analysed by both end-user terminals as well as by the SLA Management 
application 24 so that even the service provider or network operator can have a report about the 

30 QoS for the last call session and appropriate actions can be taken. 

The process can therefore include processing and/or storing the QoS data measured within the end 
user terminal and/or extracted from received messages to produce displayable QoS parameters that 
have a significance to the user or in relation to a defined SLA and displaying said parameters to a 
35 user via a suitable user interface provided by the end-user terminal or SLA management 
application. 
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Preferably, the different parameters which are representative of the QoS are included within a 
specific field, defined by a specific header within the SIP message. While the proxies can have 
access to those headers - for allowing the operator to exploit this useful information - the headers 
5 are not modified by the proxies and, therefore, all the parties can be sure to receive the same QoS 
information. 

With respect to figure 5 there is illustrated an example of the messages which are exchanged 
between end-user terminal 21 and the end-user terminal 22, as well as their associated proxies. It 
10 can be seen that, in this example, terminal 21 completes a call to terminal 22 using two proxies - 
proxy 1 and proxy 2 (not shown in figure 3). The call terminates when terminal 22 disconnects by 
initiating a BYE message. 

In accordance with the preferred embodiment, messages 112-114, 115-117 and 118-120 are used 
15 for conveying QoS information to the other party. The QoS reports may also be collected in proxy 
1 and proxy 2 in order to let all parties, including end-user 21 and 22 as well as the service 
operator (not shown on the figure) share the same QoS information. 

The following messages are exchanged: 

20 



Message 


101 from Terminal 21 to proxy 1: 


INVITE 


Message 


102 from Proxy 1 to Proxy2: 


INVITE 


Message 


103 from Proxy 1 to Terminal 21: 


100 Trying 


Message 


104 from Proxy2 to Terminal 22: 


INVITE 


Message 


105 from Proxy 2 to Proxy 1 


100 Trying 


Message 


106 from Terminal 22 to Proxy2 


180 Ringing 


Message 


107 from Proxy 2 to Proxy 1: 


180 Ringing 


Message 


108 from Proxy 1 to Terminal 21: 


180 Ringing 


Message 


109 from Terminal 22 to Proxy 2: 


200 OK 


Message 


110 from Proxy 2 to Proxy 1: 


200 OK 


Message 


111 from Proxy 1 to Terminal 21: 


200 OK 


Message 


112 from Terminal 21 to proxy 1: 


ACK 


Message 


113 from Proxy 1 to Proxy2: 


ACK 


Message 


1 14 from Proxy2 to Terminal 22: 


ACK 


Message 


115 from Terminal 22 to Proxy2: 


BYE 
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Message 1 16 from Proxy2 to Proxy 1: BYE 

Message 117 from Proxy 1 to Terminal 21: BYE 

Message 118 from Terminal 21 to proxy 1: 200 

Message 119 from Proxy 1 to Proxy2: 200 

Message 120 from Proxy2 to Terminal 22: 200 



With the following examples: 



Message 101 



INVITE sip :U serB@there.com SIP/2.0 

Via: SIP/2. 0/UDP here.com:5060;branch=z9hG4bK74bf9 

Max-Forwards: 70 

From: Big Guy < sip: User A @here. com > ;tag = 9fxced76sl 
To: LittleGuy < sip:UserB@there. com > 
Call-ID : 1234560I@here.com 
CSeq: 2 INVITE 

Contact: < sip:UserA@100. 101.102. 103 > 
Content-Type: application/ sdp 
Content-Length: 147 

v=0 

o = User A 2890844526 2890844526 IN IP4 here, com 

s= Session SDP 

c=IN IP4 100. 101 .102. 103 

t=0 0 

m =audio 491 72 RTP/A VP 0 
a = rtpmap:0 PCMU/8000 



Proxy 1 forwards the INVITE to Proxy 2. Client for A prepares to receive data on port 49172 
from the network. 

10 

Message 102 

INVITE sip :U serB@there.com SIP/2.0 

Via: SIP/2. 0/UDP ssl . wcom. com:5060; branch =z9hG4bK2d4790. 1 
Via: SIP/2. 0/UDP here.com:5060;branch=z9hG4bK74bJ9 
; received =100.101. 102. 103 
Max-Forwards: 69 

Record-Route: < sip.ssl . wcom.com; Ir > 

From: BigGuy < sip: User A @here. com > ;tag = 9pcced76sl 

To: LittleGuy < sip:UserB@there. com > 

Call-ID: 12345601@here.com 

CSeq: 2 INVITE 
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Contact: < sip:UserA@100.101 .102. 103 > 
Content-Type: application/sdp 
Content-Length: 147 

v=0 

o = UserA 2890844526 2890844526 IN IP4 here.com 
s= Session SDP 
c=INIP4 100.101 .102.103 
t=0 0 

m =audio 491 72 RTP/A VP 0 
a = rtpmap :0 PCMU/8000 



Message 103 

SIP/2.0 WOTrying 

Via: SIP/2. 0/UDP here.com:5060;branch=z9hG4bK74bf9 
received =100.101. 102. 103 

From: BigGuy < sip:UserA@here. com > ;tag = 9ficced76sl 
To: LittleGuy < sip:UserB@there. com > 
Call-ID: 12345601@here.com 
CSeq: 2 INVITE 
Content-Length: 0 



Message 104 



INVITE sip:UserB@l 10.11 1.1 12.113 SIP/2.0 

Via: SIP/2. 0/UDP ss2.wcom.com:5060;branch=z9hG4bK721e418c4J 
Via: SIP/2.0/UDP ssl .wcom.com:5060;branch=z9hG4bK2d4790.1 
;received =1.2.3.4 

Via: SIP/2. 0/UDP here.com:5060;branch=z9hG4bK74bJ9 
/received =100.101. 102. 103 
Max-Forwards: 68 

Record-Route: < sip:ss2. wcom. com;lr > , < sip:ssl . wcom. com;lr > 
From: BigGuy < sip: User A@here. com > ;tag = 9fxced76sl 
To: LittleGuy < sip:UserB@there. com > 
Call-ID: 12345601@here.com 
CSeq: 2 INVITE 

Contact: < sip:UserA@100. 101.102.103> 
Content-Type: application/sdp 
Content-Length: 147 

v=0 

o = User A 2890844526 2890844526 IN IP4 here.com 
s= Session SDP 
c=INIP4 100.101.102.103 
t=0 0 

m =audio 491 72 RTP/A VP 0 
a = rtpmap :0 PCMU/8000 
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Message 105 



SIP/2.0 100 Trying 

Via: SIP/2.0/UDP ssl .wcom.com:5060;branch=z9hG4bK2d4790.1 
; received =1.2.3.4 

Via: SIP/2. 0/UDP here. com:5060; branch =z9hG4bK74bJ9 
;received=100. 101 . 102.103 

From: BigGuy <sip:UserA@here.com> ;tag = 9pcced76sl 
To: LittleGuy <sip:UserB@there.com> 
Call-ID: 12345601@here.com 
CSeq: 2 INVITE 
Content-Length: 0 



5 Message 106 



SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP ss2.wcom.com:5060;branch=z9hG4bK721e418c4.1 
; received = 2. 3. 4. 5 

Via: SIP/2.0/UDP ssLwcom.com:5060;branch=z9hG4bK2d4790.1 
;received =1.2. 3 A 

Via: SIP/2. 0/UDP here.com:5060;branch=z9hG4bK74bJ9 
received =100.101. 102.103 

Record-Route: < sip:ss2. wcom. com;lr > , < sip:ssl . wcom.com;lr > 

From: BigGuy < sip : User A@here. com > ;tag = 9pcced76sl 

To: LittleGuy < sip:UserB@there. com > ;tag =314159 

Call-ID: 12345601@here.com 

Contact: <sip:UserB@l 10.1 11.1 12. 113> 

CSeq: 2 INVITE 

Content-Length: 0 



Message 107 



SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP ssl.wcom.com:5060;branch =z9hG4bK2d4790.1 
; received =1.2.3.4 

Via: SIP/2.0/UDP here.com:5060;branch=z9hG4bK74bj9 
;received=100. 101.102. 103 

Record-Route: <sip:ss2.wcom.com;lr> , < sip :ssl. wcom. com; lr> 

From: BigGuy <sip:UserA@here.com> ;tag=9fxced76sl 

To: LittleGuy < sip :U serB@there.com > ;tag=314159 

Call-ID: 12345601@here.com 

Contact: < sip : UserB@l 10.111. 112. 113> 

CSeq: 2 INVITE 

Content-Length: 0 



Message 108 
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SIP/2.0180 Ringing 

Via: SIP/2.0/UDP here.com:5060;branch=z9hG4bK74bf9 
;received= 100.101 . 102.103 

Record-Route: <sip:ss2.wcom.com;lr> , <sip:ssl .wcom.com;lr> 

From: BigGuy <sip:UserA@here.com> ;tag=9fxced76sl 

To: LittleGuy < sip:UserB@there. com > ;tag=314159 

Call-ID: 12345601@here.com 

Contact: < sip : UserB@l 10.111. 112. 113> 

CSeq: 2 INVITE 

Content-Length: 0 



Message 109 



SIP/2.0 200 OK 

Via: SIP/2.0/UDP ss2.wcom.com:5060;branch=z9hG4bK721e418c4.1 
; received = 2. 3. 4. 5 

Via: SIP/2. 0/UDP ssl wcom.com:5060;branch=z9hG4bK2d4790.1 
; received =1.2.3.4 

Via: SIP/2. 0/UDP here, com: 5060; branch =z9hG4bK74bf9 
.received =100.101. 102. 103 

Record-Route: < sip :ss2. wcom.com; lr> , <sip:ssl.wcom.com;lr> 
From: BigGuy < sip:UserA@here. com > ;tag = 9fxced76sl 
To: LittleGuy < sip:UserB@there.com> ;tag =31 41 59 
Call-ID: 12345601@here.com 
CSeq: 2 INVITE 

Contact: <sip:UserB@l 10.1 11.1 12. 113> 
Content-Type: application/sdp 
Content-Length: 147 

v=0 

o = UserB 2890844527 2890844527 IN IP4 there.com 
s= Session SDP 
c=INIP4 110.111.112.113 
t=0 0 

m=audio 3456 RTP/AVP 0 
a=rtpmap:0 PCMU/8000 



Message 110 



SIP/2.0 200 OK 

Via: SIP/2.0/UDP ssl.wcom.com:5060;branch=z9hG4bK2d4790.1 
; received =1.2.3.4 

Via: SIP/2.0/UDP here.com:5060;branch=z9hG4bK74bJ9 
.-received = 100. 101 . 102. 103 

Record-Route: < sip:ss2. wcom. com;lr > , < sip:ssl . wcom. com;lr > 
From: BigGuy < sip:UserA@here. com > ;tag = 9fxced76sl 
To: LittleGuy <sip:UserB@there.com> ;tag=314159 
Call-ID: 1 2345601 @here. com 

CSeq: 2 INVITE 
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Contact: < sip : UserB@l 10.111 .112 .113> 
Content-Type: application/ sdp 
Content-Length: 147 

v=0 

o = UserB 2890844527 2890844527 IN IP4 there.com 
s= Session SDP 
c=INIP4 110.111.112.113 
t=00 

m= audio 3456 RTP/AVP 0 
a=rtpmap:0 PCMU/8000 



Message 111 



SIP/2.0 200 OK 

Via: SIP/2.0/UDP here.com:5060;branch=z9hG4bK74bf9 
received =100. 101 . 102.103 

Record-Route: <sip:ss2.wcom.com;lr> , <sip:ssl .wcom.com;lr> 
From: BigGuy < sip: User A @here. com > ;tag = 9fxced76sl 
To: LittleGuy < sip:UserB@there. com > ;tag =314159 
Call-ID: 12345601@here.com 
CSeq: 2 INVITE 

Contact: < sip:UserB@110. 111.1 12. 113> 
Content-Type: application/sdp 
Content-Length: 147 

v=0 

o = UserB 2890844527 2890844527 IN IP4 there.com 
s= Session SDP 
c=INIP4 110.111.112.113 
t=0 0 

m=audio 3456 RTP/AVP 0 
a=rtpmap:0 PCMU/8000 



Message 112 



ACK sip:UserB@l 10.1 11. 112.1 13 SIP/2.0 

Via: SIP/2. 0/UDP herexom:5060;branch=z9hG4bK74bf9 

Max-Forwards: 70 

Route: < sip:ssl . wcom. com;lr > , < sip:ss2. wcom. com;lr > 
From: BigGuy < sip:UserA@here. com > ;tag = 9fxced76sl 
To: LittleGuy < sip:UserB@there. com > ;tag = 31 4159 
Call-ID: 12345601@here.com 
CSeq: 2 ACK 

QoS-Report: domain = signalling ;i- 100= 75 3ms ;i- 180= 945ms 
Content-Length: 0 
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In this message, User A has inserted a QoS-Report header to provide statistics on the call setup. 
5 The report is related to the signalling domain (domain = signalling) and two measurements are 
provided: the time between the INVITE and the 100 Trying, and the time between the INVITE and 
the 180 Ringing. Using this information, Proxy 1 may update a Call Details Record (CDR) by 
conventional means that need not be described herein. The QoS-Report header is forwarded 
unmodified. 

0 

Message 113 



ACK sip:UserB@110.111. 112,113 SIP/2.0 

Via: SIP/2. 0/UDP ssl .wcom.com:5060;branch=z9hG4bK2d4790.1 
Via: SIP/2.0/UDP here.com:5060;branch=z9hG4bK74bf9 
received = 100 J 01 . 102. 1 03 
Max-Forwards: 69 
Route: < sip:ss2. wcom.com;lr > 

From: BigGuy < sip .User A@here. com> ;tag = 9pcced76sl 
To: LittleGuy < sip: UserB@there. com > ;tag = 314159 
Call-ID: 12345601@here.com 
CSeq:2ACK 

QoS-Report: domain = signalling ;i- 100= 75 3ms ;i- 180= 945ms 
Content-Length: 0 



Message 114 



ACK sip:UserB@l 10.1 11.1 12.1 13 SIP/2.0 

Via: SIP/2. 0/UDP ss2. wcom. com:5060;branch =z9hG4bK721e418c4. 1 
Via: SIP/2. 0/UDP ssl .wcom.com:5060;branch=z9hG4bK2d4790.1 
; received =1.2.3.4 

Via: S1P/2.0/UDP here.com:5060;branch=z9hG4bK74bJ9 
;received=100.101 .102. 103 
Max-Forwards: 68 

From: BigGuy <sip:UserA@here.com> ;tag =9pcced76sl 
To: LittleGuy < sip :U serB@there.com > ;tag =314159 
Call-ID: 12345601@here.com 
CSeq:2ACK 

QoS-Report: domain = signalling ;i- 100 = 753ms;i-l 80 = 945ms 
Content-Length: 0 



20 

RTP streams are established between A and B. 
User B hangs up with user A. 

14 
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Message 115 



BYE sip:UserA@100. 101 .102.103 SIP/2.0 

Via: SIP/2.0/UDP there. com :5060;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route: < sip:ss2. wcom. com;lr > , < sip:ssl . wcom. com;lr > 
From: LittleGuy < sip: UserB@there. com > ;tag = 31 4159 
To: BigGuy <sip:UserA@here.com> ;tag=9fxced76sl 
Call-ID: 12345601@here.com 
CSeq: 1 BYE 

QoS-Report: domain = media; c= IN IP4 110.11 1.1 12. 113;m=audio 3456 RTP/AVP 0 
;loss = 1.79%;jitter=24ms 
Content-Length: 0 



The call is now terminated, and User B has media statistics available for transmission to its 
outbound proxy (Proxy 2). Therefore, User B generates a QoS-Report header for the media 
domain, copies the media stream identification information, and provides loss and jitter 
10 measurements. Proxy 2 may then update its CDR information. 

Message 116 



BYE sip:UserA@100.101. 102.103 SIP/2.0 

Via: SIP/2. 0/UDP ss2.wcom.com:5060;branch=z9hG4bK721e418c4.1 
Via: SIP/2.0/UDP there. com:5060;branch=z9hG4bKnashds7 
;received=l 10.111. 112. 113 
Max-Forwards: 69 
Route: < sip.ssl . wcomxom;lr > 

From: LittleGuy < sip:UserB@there. com > ;tag— 314159 
To: BigGuy <sip:UserA@here.com> ;tag=9fxced76sl 
Call-ID: 12345601@here.com 
CSeq: 1 BYE 

QoS-Report: domain = media; c= IN IP4 110.111. 112. 113;m=audio 3456 RTP/AVP 0 
;loss=l. 79%; jitter =24ms 
Content-Length: 0 



Message 117 



BYE sip:UserA@100.101. 102.103 SIP/2.0 

Via: SIP/2. 0/UDP ssl .wcom.com:5060;branch=z9hG4bK2d4790.1 
Via: SIP/2.0/UDP ss2.wcom.com:5060;branch=z9hG4bK721e418c4.1 
;received=2.3.4.5 

Via: SIP/2. 0/UDP there. com:5060;branch=z9hG4bKnashds7 
;received= 110.111. 112.113 

Max-Forwards: 68 

15 
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From: LittleGuy < sip: UserB@there. com > ;tag = 31 4159 
To: BigGuy < sip: User A@here. com > ;tag — 9fxced76sl 
Call-ID: 12345601@here.com 
CSeq: 1 BYE 

QoS-Report: domain = media; c = IN IP4 110.111. 112.113;m=audio 3456 RTP/AVP 0 
;loss=l. 79%;jitter=24ms 
Content-Length: 0 



Message 118 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP ssl.wcom.com:5060;branch=z9hG4bK2d4790.1 
; received —1.2.3.4 

Via: SIP/2.0/UDP ss2.wcom.com:5060;branch=z9hG4bK721e418c4.1 
; received —2.3.4.5 

Via: SIP/2.0/UDP there. com:5060;branch=z9hG4bKnashds7 
;received=110.111A12A13 

From: LittleGuy < sip:UserB@there.com> ;tag=314159 
To: BigGuy <sip:UserA@here.com> ;tag—9fxced76sl 
Call-ID: 12345601@here.com 
CSeq: 1 BYE 

QoS-Report: domain = media; c= IN IP4 110.111. 112. 113;m=audio 3456 RTP/AVP 0 
;loss = 0. 23 %; jitter = 31ms 
Content-Length: 0 



User A sends its media statistics to its outbound proxy (Proxy 1) in a similar way User 
10 B did before. 

Message 119 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP ss2.wcom.com:5060;branch =z9hG4bK721e418c4.T 
; received = 2. 3. 4. 5 

Via: SIP/2. 0/UDP there. com:5060;branch =z9hG4bKnashds7 
; received = 100. 1 01 . 102.103 

From: LittleGuy < sip: UserB@there.com > ;tag— 314159 
To: BigGuy <sip:UserA@here.com> ;tag=9fxced76sl 
Call-ID: 12345601@here.com 
CSeq: 1 BYE 

QoS-Report: domain — media; c— IN IP4 110.111. 112J13;m=audio 3456 RTP/AVP 0 
;loss = 0. 23 % jitter = 31ms 
Content-Length: 0 
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SIP/2.0 200 OK 

Via: SIP/2.0/UDP there. com:5060;branch=z9hG4bKnashds7 
;received=110.111.112.113 

From: LittleGuy < sip:UserB@there.com> ;tag— 314159 
To: BigGuy < sip: VserA@here.com > ;tag=9fxced76sl 
Call-ID: 12345601@here.com 
CSeq: 1 BYE 

QoS-Report: domain = media; c= IN IP4 110.111. 112. 113;m=audio 3456 RTP/AVP 0 
;loss =0.23% Jitter =3 lms 
Content-Length: 0 



The QoS information is carried in the header of a SIP message, as for the SDP RFC 2327, in a 
5 manner similar to that used for a document attachment for an email message, or a web page that is 
carried in an Hyper Text Transfer Protocol (HTTP) message. The advantage of inserting the QoS 
information within the header instead of using the body of the message is substantial since the 
header remains unaffected when the message is processed through the proxies and, therefore, the 
QoS information remains intact. 

10 

Preferably, QoS information is collected during the whole session and is then transmitted at the end 
of the transaction in a SIP message which is used for terminating the call. 

In the example shown in figure 5, QoS statistics for terminal 22 are conveyed via the message 
15 (BYE) message 115 and collected by Proxy2. The QoS statistics for terminal 21 is carried by 
message 118 and collected by Proxy 1 . 

In this embodiment, such statistics information comprise information relating to the signaling 
domain and information relating to the media domain . 

20 

Regarding the signaling domain the following parameters can be used, or instance: the i-100, i-180 
and r-200. 

The i-100 parameter corresponds to the time elapsed between an INVITE and the corresponding 
25 100 Trying message. It is expressed in milliseconds. This gives an estimate of the time it takes 
between the UAC initiating a call and the first proxy actually forwarding it. This parameter is sent 
in the ACK message 112 that follows the 200 OK message 111 for the INVITE 101. 
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The i-180 parameter measures the time elapsed between an INVITE and the corresponding 180 
Ringing message 108. It is expressed in milliseconds. This value represents the time a user has to 
wait between initiating a call, and receiving a confirmation that the remote party, is being alerted. 
This parameter is sent in the ACK that follows the 200 OK for the INVITE. 

5 

The r-200 parameter evaluates the time needed for registration of the UAC. It is the time between 
the REGISTER message and the corresponding 200 OK. This parameter is sent in the 200 OK 
related to the REGISTER, 

10 Belonging to the media domain are parameters that are closely related to the quality of transmission 
of the media. QoS information relating to this domain is transmitted at the end of the call, that is 
to say in the BYE message 115 or the 200 OK message 118. Parameters such as the total number 
of lost packets and the jitter are reported in this way: 

15 QoS-Report: domain = signalling; i- 100= 753ms ; i-180 =945 ms 

Qog-Report: domain=media; c = YN IP4= 10.0.0.1 ;m=audio 1970 RTP/AVP 0, 
loss=0.67%;jitter=29ms 

C and m parameters are used for identifying the type of media stream for which QoS statistics are 
20 being provided . Preferably, they can be directly derived from the contents of the SDP message. 

It can be seen that the above described techniques provide a simple mechanism that enables the 
different parties to a service agreement to share the same information about the quality of service 
in order to check compliance of the service obtained with the service level agreements (SLA) 

25 involved. However, the technique also has other advantages. The QoS information which is 
shared between the end-user terminals exactly corresponds to the quality of the service which is 
actually measured by the end user terminal. The process is not intrusive since no specific agent 
has to be deployed within the network - a substantial advantage which respect to the traditional 
probes, active and passive. The measurement of the QoS does not generate additional traffic. It 

30 can also be seen that the process which was described above does not need any dedicated protocol 
since it can take support from the existing signaling protocols. Finally, the process can provide 
privacy since embodiments can be realised in which the user is given the option not to transmit any 
QoS information if this is inappropriate or undesirable. 
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The invention has been particularly described in relation to voice services, but it will be understood 
the above techniques can be applied to any kind of media, such as video and any kind of 
applications such as multimedia services. 
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